home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / amiga.programming / comp.sys.amiga.applications_4392_000040.msg < prev    next >
Encoding:
Text File  |  1994-11-27  |  3.9 KB  |  81 lines

  1. Newsgroups: comp.sys.amiga.applications,comp.sys.amiga.programmer
  2. Path: dd.chalmers.se!news.chalmers.se!sunic!trane.uninett.no!eunet.no!EU.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!math.fu-berlin.de!hpcsst.mppmu.mpg.de!postmaster
  3. From: "Stefan Stuntz" <stuntz@informatik.tu-muenchen.de>
  4. Subject: Re: MUI 2.0 bug!
  5. Content-Type: text/plain; charset=iso-8859-1
  6. Message-ID: <64531381@hpcsst.mppmu.mpg.de>
  7. Sender: news@math.fu-berlin.de (Math Department)
  8. Nntp-Posting-Host: hpcsst.mppmu.mpg.de
  9. Content-Transfer-Encoding: 8bit
  10. Organization: Home of MUI and MFR.
  11. X-Newsreader: IntuiNews 1.2 Beta 17 (5.2.94)
  12. References: <2lndmr$5u0@helios.ffi.no> <64531299@hpcsst.mppmu.mpg.de> <2lp6sl$c2k@helios.ffi.no> <2m123n$8nc@helios.ffi.no> <64531322@hpcsst.mppmu.mpg.de> <2m4e0r$f8v@hpsystem1.informatik.tu-muenchen.de> <2m4l6t$ng4@helios.ffi.no> <2m71kn$kta@hpsystem1.informatik.tu-muenchen.de> <1994Mar17.154855@informatik.uni-kl.de>
  13. Mime-Version: 1.0
  14. Date: Thu, 17 Mar 1994 23:05:26 GMT
  15. Lines: 64
  16. Xref: dd.chalmers.se comp.sys.amiga.applications:4392 comp.sys.amiga.programmer:7607
  17.  
  18. Christoph Feck wrote:
  19.  
  20. CF> Wrong.  MUI uses only rootclass which actually is in no way
  21. CF> related to Intuition (the fact that BOOPSI functions are in
  22. CF> intuition.library doesn't mean that rootclass is based on
  23. CF> Intuition functions.
  24.  
  25. Correct. I would have loved to do all my works based on gadgetclass,
  26. but it turned out that this class is just too silly for auto-layout
  27. GUIs. The most important thing for such a GUI is that all their
  28. contents to know about their min/max/default sizes before a
  29. parent window is actually opened. This implies some kind
  30. of setup method with environment information (fonts, etc.).
  31. Neither gadgetclass nor any other classes distributed by
  32. Commodore are capable of doing such things (not in V37, not
  33. in V38, not in V39, not in V40, maybe never?), it seems noone
  34. there ever thaught about auto-layout. These types of boopsi
  35. gadgets are completely useless for creating automatic,
  36. font-sensitive user interfaces.
  37.  
  38. But since there are some really nice boopsi gadgets flowing
  39. around (colorwheel, gradient slider, etc.), I wrote
  40. a boopsi interface class for MUI, which allows every subclass
  41. of gadgetclass to be used as MUI object in a MUI window.
  42. Due to the missing features of gadgetclass, there are
  43. some drawbacks (e.g. the programmer needs to specify min/max
  44. sizes when creating the object), but it works.
  45.  
  46. CF> MUIs area class is NOT based on gadgetclass.  Of course,
  47. CF> this has both downsides and upsides.  I think starting with
  48. CF> OS 3.0 it makes more sense to base such a system on
  49. CF> gadgetclass (hint hint ;)
  50.  
  51. Sorry, I can't see any automatic layout capabilities in OS 3.0.
  52. Maybe you could tell us a bit more about this. BTW, I don't call
  53. GFLG_RELxxxxx flags automatic layout, I call it nonsense :-)
  54.  
  55. CF> Of course letting MUI run on the applications process isn't
  56. CF> bad either.
  57.  
  58. It's the only way accomplish certain goals. Did you ever try to
  59. make an intuition gadget pay attention to clip regions? Virtual
  60. groups would be impossible with your user interface running
  61. on several different tasks.
  62.  
  63. Yes, sometimes its nice to have input.device.task handle gadgets.
  64. That's why the Amiga has the best "prop gadget feeling" of every
  65. platform and that's why I decided to have MUI's prop gadgets also
  66. handled by input.device.task. But having a complete user interface
  67. under input.device control is simply not necessary and brings up
  68. lots of refreshing problems.
  69.  
  70. CF> It replaces gadgetclass, which is not only the baseclass of
  71. CF> all gadgets in the system, but also the superclass for any
  72. CF> gadgets we have (like colorwheel, datatypes etc.), and for
  73. CF> any gadgets we will see in the future (apart from new MUI
  74. CF> classes :)
  75.  
  76. True. But due to MUIs boopsi interface class, all MUI applications
  77. can benefit from new boopsi classes. Of course things would be
  78. a bit nicer with new MUI classes... :-)
  79.  
  80. Greetings, Stefan.
  81.